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(54) Database network 

(57) A method and apparatus for publishing and 
receiving events to a network (120). A plurality of "pub- 
lisher" entities publish information and a plurality of 
"subscriber entities request and use the information. 
Publishers (102, 110, 116) and subscribers (104, 112, 
1 18) are connected to each other through a network 
(120). The network (120) is a "store and forward" net- 
work whose routing is "content-based." The basic 
quanta of information is called an "event." Publishers 
(102, 110, 116) publish events and subscribers (104, 
112, 118) subscribe to events that match criteria 
defined by the subscriber (104, 112, 118). Publication 
and subscription are performed asynchronously. Pub- 
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lishers (102, 110. 116) and subscribers (104, 112, 118) 
do not have direct knowledge of each other. The system 
(100) receives a published event from a publisher (102, 
110, 116) and routes the event to all appropriate sub- 
scribers (104, 112, 118). Each subscriber (104, 112, 
118) is guaranteed to receive all events published on 
the system (100) if, and only if, they match the subscrip- 
tion criteria specified by the subscriber. A legacy data 
base can be added to the network by way of a data base 
connector, which can be a publisher, a subscriber, or 
both. 
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ing systems and running various types of applications. The described embodiment utilizes a d >* rib **^^ 
mem and a preferred embodiment of the present invention implements the Common Object Request Broker (CORBA) 

In accordance with the purpose of the invention, as embodied and broadly described herein, the invention , relates 
,o a method of connecting a data base to a publisher/subscriber network, so that the data base ™ ^ 
the network, the method comprising the steps, performed by the data processing system, of: proving a link sol that the 
data base can communicate with a data base connector computer program by way of a transaction monrto ^omputer 
Droqram- setting up the data base connector as a publisher hub in the network; receiving input, by the data base, from 
a uler LSers data in the data base; informing the transaction monitor that the data has been 
from the user indicating that the altered data should be committed; informing the transact™ monitor that the .altered 
data is committed; and sending, by the data base connector, in accordance with a message from the transaction mon- 
itor that the data is committed, a published event to the network in accordance with the altered data. 

Objects and advantages of the invention will be set forth in part in the description which follows and in part will be 
obvious from the description or may be learned by practice of the invention. The objects and advantages of the inven- 
tion will be. realized and attained by means of the elements and combinations particularly pointed out in the appended 
claims and equivalents. 

Brief Description of the Drawings 

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several 
embodiments of the invention and. together with the description, serve to explain the principles of the jnventon. 

Fig 1 is a block diagram of a networked computer system in accordance with a preferred embodiment of the 

present invention. . . . c . , 

Fig 2 is a flow chart showing steps performed to install an application, such as a publisher, on a hub of Fig. 1 . 
25 Fig 3 is a flow chart showing steps performed by a publisher of Fig. 1 to publish events. 

Fig: 4 is a flow chart showing steps performed by a subscriber of Fig. 1 to subscribe to events. 
Fig. 5 is a block diagram showing details of a hub of Fig. 1 . 

Fig. 6(a) is a diagram showing data structures stored in a memory of the hub of Fig. 5. 

Fia 6(b) is a listing of details of the data structures of Fig. 6(a). . 
30 Fig. 7 is a diagram of additional data structures stored in the memory of the hub of Fig. 5 for the purpose of storing 
information about clients of the hub. 

Fig. 8 shows a format of an envelope data structure of an event. 
Fia 9 shows a format of a routing block of an event. 

Fig. 10 is a flow chart showing details of steps performed by the hubs of Fig. 1 to populate the data structures of 

F ' 9 2? 11 is a diagram showing examples of the data structures of Fig. 6(a) populated with data. . 

Fig. 12 is a flow chart showing details of steps performed by the hubs of Fig. 1 to send published events to sub- 
scribers. c . ., 

Fig. 13 is a block diagram of a data base application incorporated into the network of Fig. i. 
40 Fig. 1 4 is a flow chart showing steps performed when the data base is a subscriber. 

Fig. 1 5 is a flow chart showing steps performed when the data base is a publisher 

Detailed Description of the Preferred Embodiments 

Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illus- 
trated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the 
drawings to refer to the same or like parts. 
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Fig 1 is a block diagram of a networked computer system 100 in accordance with a preferred embodiment of the 
present invention. Networked computer system 100 includes a plurality of publishers 102. 110. and 1 16 and a plurality 
of subscribers 104 1 12. and 1 18. Publisher 102 and subscriber 104 are connected to a network 120 through a hub 106. 
Publisher 1 10 and 'subscriber 1 12 are connected to network 120 through a hub 108. Publisher 1 16 and subscriber 118 
are connected to network 120 through a hub 114. Hub 106 and its connected publishers and subscribers are in a firs 
territory 130 Hubs 108 and 1 14 and their connected publishers and subscribers are in a second territory 140. Other 
territories (not shown) also exist in network 120. "Hubs." "publishers." "subscribers." and "territories" are discussed 

bel0 A S ,r indic n ated by dotted lines in Fig. 1. each publisher, subscriber, and hub can be located in separate computers 
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//filename: order.ddl 

interface SalesOrder { 
5 struct Address { 

string street; 
string city; 
string state; 

*o unsigned long zip; 

}; 

attribute string customer_name; 
is attribute Address customer„address; 

}; 
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Tha above syntax defines an event as an "interface" and defines the data members in the event as attributes. 
IJter onTor mole evenTs have been defined, the events are transited into structure definitions of the C program- 
mine ^nauaa ^ P^eraWy this translation is performed by an OMG IDL compiler, which generates a header file and a 
He for Sc.! ^etemfhe generated headerfile contains simple C-language structures that represent the event dee- 
pens ^ in the code fi.e. The C structure definition generated for the above example 
event of type SalesOrder is: 

typedef struct SalesOrder.Address { 
30 nxsString street; 

nxsString city; 
nxsString state; 
nxsULong zip; 

35 } SalesOrder_Address; 

typedef struct SalesOrder { 

nxsString customer_name; 
40 SalesOrder_address customer_address; 

} SalesOrder; 

45 A person of ordinary skill in the art will easily understand how the IDL of the example translates into the C programming 

^xi^s&'sz — « «— >— — » — °* *• de,inea '** 

(here, for the SalesOrder event). The procedures perform at least the following operat.ons: 
so For use bv g publisher: 

Create event of type SalesOrder, 
Publish event of type SalesOrder, 

55 

Destroy event of type SalesOrder 
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that a oublisher could execute and send those events. This information is needed to build routes to subscribers as 
describ^ ^eZ^o^s^ in the Figure, other publishers connected to the same hub may operate asynchro- 
nously with the steps of Fig. 3. 

Subscribers subscribe to events ot particular event types. Fig. 4 is a flow chart sr.ow.ng s eps Performed by a i sub- 
scriber o'Z i I during operation of the subscriber. The subscriber first registers itself as a Cent of the hub. Then for 
each subscription, it registers a "call-back" procedure. -rhoenh 

As shown in step 402. the subscriber next registers itself as a client with the hub to wh.ch .t is connected. The sub- 
scriber £ TreglsTers a "subscription" for the event type that it wishes to receive through the hub. (The «^«rte can 
Sk a he hu?to see what types of events are advertised.) A subscription specifies a type of event and can further 
£ed» a W Seating thaUhe subscriber wishes to receive only events of a certain type that a.so have certam val- 

U6S In 2?5J!!S each subscription, the publisher defines a predetermined "call-back" procedure. The ^^kpro- 
cedure wi? be initiated by the hub whenever the hub determines that the subscriber has received an event of a certain 
?vpe The format of the callback may be different for each operating system on which the present '"vent-on isjmple- 
Sd^eSw** procedure can be practically any procedure that is performed when an event « rece,ved^Fo 
Example in step 406 of Fig. 4. the call-back procedure could print the contents of the event (using one of the ^nt 
manT D ufat on procedures designed to print an event of that type). Because a call-back procedure is defined for each 
^script on SZZZSpnJ**. must be defined for each type of event to which the subscriber plans to subscribe^ 
SSSi embodiment, an event passed into a call-back procedure is destroyed when the 
returns Thus if the subscriber wants to keep any information of the event, the .nformat.on should be copied out of the 

^ZSSXZZF*. - cease execution (see step 40* Th. ca,ba* ^JJ^^ 
zero. one. or many times during this loop, as events of the specified type and values are " "Jj 

subscribed to by the subscriber is received, the call-back procedures is executed in step 406; H. in step 408. the > sub 
££k££2~ that it is time for it to quit, the subscriber optionally unregisters its subscription, unregisters itself wrfh 
me hub , «S ceases execution. Subscriptions can also be retained in the hub. to receive future events while ctacon- 
I^T^lSflSSSe events arriving for the subscriptions. Although not shown in the Figure, other subscribers 
connected to the same hub may perform steps asynchronously with the steps of Fig. 4. 
The following examples are written in the C programming 
30 language and show example software for a publisher and subscriber. 
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return (0) ; 

} 

/• 

* subscriber 
V 

#include <nexus.h> 

#include "nxs.output/order.nxs.h" 

/* Callback function to be called when each event is received V 
void event_callback ( 

nxsClientID id, 

nxsSubscriptionID subjd, 

nsxULong seq.num.high, 

nsxULong seq.num.low, 

SalesOrder *the_event, 

void *client_data) 

{ 

char *st; 

printf ("Event received! \n"); 

st = nxsStringify_SalesOrder(the.event); 

printf(st); 
free (st); 

} 

int main(int argc, char **argv) 
{ 

Sales Order *event; 

nxsClient ID id; 

nxsSubscriptionID sub.id; 

/* Register Client and subscription */ 

7* (Only subscribe to specific ZIP codes) V 

nxsCreateClient ("order subscriber",NULL,NULL, 0,&id); 

nxsRegisterSubscription SalesOrder (id, 

"customer_address.zip == 95000", 

e vent.callback^NULL,&sub jd) ; 
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of events and only pass events to the subscribers that match certain criteria. A filter preferably is specified as a expres- 

£ the subscriber as a parameter to the routine for registering 
tax for a content filter in the described embodiment is as follows. (Of course, any appropriate syntax could be used). 



15 



symbol meaning 


types allowed for 




equal to 


all basic types 




not equal to 


all basic types 


> 


greater than 


numeric and string types 


>=, <= 


greater than or equal 


numeric and string types 


and 


logical AND 


expressions or Booleans 


or 


logical OR 


expressions or Booleans 


not 


logical NOT 


expressions or Booleans 
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Event attribute names are used to denote which field in the event should be compared. Sub-fields (those .ns.de 
structures) are specified using dot notation. Names can also be enumerated types, as is known to persons familiar wrth 
the C programming language. Once a content filter has been specified, it is used during event routing as described 
below in connection wrth Figs. 8-12. Information describing each content filter for a subscr.pt.on .s stored in field 774 of 

F ' 9 ' Fig 6(a) is a diagram showing data structures stored in a memory 690 of hub 106 of Fig. 5. All hubs contain similar 
data sttuctures. The described implementation uses a distributed objects model, but any 'W^^^f'^ 
structure could be used. Details of the data structures of Fig. 6(a) are listed in Fig. 6(b). Ideally, the structures of 
Fig 6(a) describe all advertisements in the system and indicates a neighbor hub to which the current hub should send 
events of certain types. Figs. 10 and 12. respectively, describe the steps to populate the data structures of Fig. 6(a) and 
to use to the data structures of Fig. 6(a) to route events among the hubs. F,g. 1 1 shows an example of the data struc- 

,Ure hSiOS Ohe* "cur'Snt hub") includes data objects representing: each client of the current hub that is a subscriber 
(indicated by "Client" 684 and "S" 695) and each neighboring hub connected to the current hub ( Neighbor A 696 and 
"Neiohbor B" 697) The current hub keeps track of the subscription objects of its neighbor hubs. Subscription objects 
"S- 650 represent all subscribers that can be reached through the respective neighbors. Each neighbor object has two 
associated cost values: "mycost" and "theircost". "Mycost" represents a cost of sending informat.on from the current 
hub to the neighbor. "Theircost" represents a cost of sending information from the neighbor to the curren hub "Their- 
cosf used to define a route, as described below. The subscribing hub will ask the "publishing" hub with theses their- 
cost" to forward the events. "Mycost" preferably is only used to inform the neighbors of how much it would cost to the 
current hub to send information through that link. A "cost" may be figured in a number of ways. For example, a cost may 
represent a financial cost, a cost in units of time, a cost as a measure of convenience, or any other ^appropnate cost 
Hub 106 contains a CRemoteAd") object for each advertisement that has been registered in the system (..e. fo 
each intent to publish, step 202 of Fig. 2). Each RemoteAd object points to one or more "AdSource ob ^^ ch °' 
which represents a path between the current hub and the hub on which the publisher of the ad res,des. Each AdSource 
object stores a cost associated with its path to the original publisher of the ad. Thus, the "cost value for each AdSource 
contains the total cost for sending an event from its source to the neighbor of the current hub or. alternately, to the cur- 

fent Each AdSource object has an associated list of "sink objects." (SinkCa and sinkNb preferably are located in a sin- 
gle list, although not shown that way in the Figure.) Each sink object has an associated list of subsa.pt.ons. For exam- 
ple SinkCa has a list 505 of all subscriptions of Client 694 that matched to the advert.sement of RemoteAd 510^ 
Similarly. SinkNb has a list 515 of all subscriptions of Neighbor B (and of all subscriptions that can be reached through 
Neighbors) that have matched the advertisement of RemoteAd 510. a 
Each neighbor object also has an associated AdSourceRef list that points to AdSources for all paths between a 
publisher and the neighbor. The paths are used for routing system events between hubs, as described below. 

IV. Event Routing Between Hubs 

Fig 10 is a flow chart showing details of steps performed by hubs 106. 108. and 1 14 of Fig. 1 to populate the data 
structures of Fig. 6(a). These steps are performed, for example, when the network is first initialized. Subsequently, var- 
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(step 1203). The steps of Fig. 12 are performed by various hubs as each event is routed through the system. In the ft* 
owing paragraphs, the hub performing the steps of Fig. 12 is termed the current hub. 
. If the current hub receives an event from one of its connected publishers (step 1202). the 

" ^ ^T^tJZZ^ ** - -nt from the current hub, incoming event queue 61. 
then inc events he time-spent field of the envelope, which indicates an amount of time spent in queue In step 1210 
filter sTe adds a routing bS to the event. Each hub that routes the event adds another rSuting Nock to the event. A 

"Tn Sep ^te^e* huM^a'current" AdSource object that represents all the subscribe, which are 
interest in the eve* colg from that particu.ar AdSource. This will usually represent a least a cosl i pat . between the 
S^^iS^-fcKribU (note that the described embodiment does not reroute once an AdSource , date struc- 
te iSJShed The AdSource object is located by either searching all RemoteAds for the current hub ('"he even 

^^XXS^Z^*^^ .--spent fie.d of the envelope then the event has 
expi ed aSTs ^ ro^i further by the current hub (step 1218). Othen^ise. in step 1220. filter 518 
fhTevenTnas contents that fall within parameters specified by the subscriber. The subscr.berspecrf.ed the content Jrfter 
?«£^£b£n^ to the event type (see fie.d 774 of Fig. 7). For example, a subscnber may have requited to 
receive Tn.^ tnose SalesEvents havin^where the customer .ives in Los Angeles. If the evert has values .n he range 
spei by he subscriber, then the event is sent to the subscriber in step 1222 (either direct y °^y ^ °f rts h u as 
Ho!Sih^ Thelow) Each subscriber may have specified a different content filter (or no content f .Her). For example, a first 

Ibl^ 

ondtutecrtoe? may have specified that it wishes to receive SalesEvents where the customer hvesm San Francsco. In 
52 exSS e it is possible mat the event will match the first subscriber but not the second subscr.be 

TZ 1222 S 518 sends the event to the matching subscriber. The subscriber may be a Cent of th e cun-ent 
hub n wh'h else the event is sent directly to the subscriber. A'ternate.y the subscribe^ 
horina hub either directly or indirectly. If a matching subscriber is connected to a neighboring hub. the current hub wm 
^ft^^JSSn^ hub (un.ess the neighboring hub is the hub originating ttie event as deleted from 
fTeW 802 of 5?e envelope see Fig. 8). The current hub also will not route the event to a hub that has already seen the 
fiwfini / a c Hptermined from the routing blocks attached to the event, see Fig. 9). # u 

^ t rhVdtc^embodiment. th! current hub only routes the event to a neighbor^ hub a ^single , ime^even the 
« neighboring hub has more than one matching subscription. Thus, if subscripton object 651 of Fig. W m>**^ 
event the event is forwarded to neighboring hub B. If subscription object 652 also matches the event, it .s not necessary 
"Sward thetent to the neighboring hub B a second time. When neighboring h* B ^receives the event, rt also w... 
nprformthesteDSof Fig 12 to determine whether any of its client subsenbers match the event. 
P Z YjSZ t for™ t o an envelope data structure of an event. The preprocessor of Fig^ adds an envelope to 
« an evL r^ fro^S subscriber before the event is published. An envelope is associated with each event and 
fn^lSes aTo Sn hub 802. an adname 804, a publisher name 806. a territory name 808. an initial time s^ m 
^elo Hve 812. a priority 814. flags 816. and a time spent field 822. Flags 816 are unused " ^ embodi- 
ment In an alternate embodiment, the flags may indicate, e.g.. whether an event '^'^1°^ ^ event that 
Pin q shows an example format of two routing blocks of an event. Each hub adds a rout.ng block to an event tha 
. 9 I h ?Zh^Tap7^ includes a get current route info routine that returns information about the actual 

en^ry or each Z *Z ted. Each entry includes: an outgoing time stamp for the current hub , . i hu > name oHh > cu.ent 
hub and a territory name of the current hub. The routing information optionally .ncludes a sixty-four bit sequence 
number initially assigned to the event by the publisher 
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V. Territories 



Each territory 130 and 140 of Fig. 1 is a collection of hubs with a common event dictionary Territories refled torgan- 
izatior "anc [aren^t necessarily tied* geography or direct physical connectivity, .n the descr-bed embod.ment. all hubs 
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If. in step 1507. the user (or software making changes) indicates that the transaction sh ould ' ^ J 

communicated to transaction monitor 1306 in step 1510. Transaction ^^J^«"^ 
which pulls the committed data from data base 1308 and publishes an event including the ^ommitt ed I data. Event ^e 
published as shown in Fig. 12. If. in step 1512 the user (or software making changes) ^J^J^S^K 
should roll back this fact is communicated to transaction monitor 1306. Transact.on monrtor 1306mforms data base 
connito 1310.' which "forgets" about the changes of step 1506 and does not publish an event Thus .the descried 
embcSment takes into accent the commitment and roll back operations common to commeraal data base operation. 

in an alternate embodiment, where the data base product 1302 used does not include ^transaction monitor « data 
base connector 1310 can act as a transaction monitor when connecting with data base 1308. Data base connector 
?310 sJacteas a publisher and/or subscriber in this configuration. Data base 1308 thinks that rt ,s connected to a 
transaction monitor, when it is really connected to data base connector 1310. 

VII. Summary 

In summary, a preferred embodiment of the present invention includes a plurality of "publisher" entities who publish 
information, and a plurality of "subscriber" entities, who request and use the information. Publishers and ^cnbers 
are connected to each other through a network. The network is a "store and forward" network whose routing .s content- 

b3S 1n'the described embodiment of the present invention, the basic quanta of information is called an "event' 'Publish- 
ers publish events and subscribers subscribe to events that match criteria defined by the sub «^ p "™"^ 
subscription are performed asynchronously. Publishers and subscribers do not have direct 

The svstem receives published event from a publisher and routes the event to all appropriate subscribers Each sub- 
SbeM^aranr e S to receive all events published on the system if. and only if. they match the subscr.pt.on cntena 

^^de^ibed^rnbodiment of the present invention makes it easy to integrate legacy systems, legacy applications, 
and legacy hardware into the system and attempts to minimize the amount of information that a user must les irn Mto , use 
the system. A legacy data base can be added to the network by way of a data base connector. wh.ch can be a pubhsher. 

3 ^Sher'rm^ments will be apparent to those skilled in the art from consideration of the specification and practice 
: of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, 
with a true scope of the invention being indicated by the following claims. 

APPENDIX A 
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Object references are trtnsfered in srjringined form. 

System cvcnn are used for several styles of ccmniuaicArioo. During coonectioc 
JJbLishmeni system even* are used as peer-to-pecr messages. The* events sre not 
seen by other hobs. Most other even* afto the state of me territory ndmiyte 
forward mrough^ 

NXS.SYS.EVENT.CONNBCT.HUB 

/string/ Sending hub name 

/string/ Sending hub territory 

string Sending hub incoming Even t Que ue :: Pu^hCon suae r 

along Receiving bub' a coat 

along Sending hub' s cost 

This event is sent is i result of t call to Ncxcs > ^ m"Hn hAdiniii~ ^ The 
c^rvW bnb has already created the Neighbor and EvenrQueoe for the rmryr nnn The 
receiving hub does likewise when it receives the system event. Note that the tending 
bob already his the incoming EveoiQuH>e:'JW 1 Cc«ain» of the lecerving via an 
arpanent io NcrosA dmhi-rmhA diiim^ If thU is the first rnrtnrrnnn for 

,hcieceivingtabGt«jot^ 

(event types, etc,). System events are nsrd to request this information from the «a*fing 
hub; NXS SYS^EVTKT.RHJUEST^EV^rrTYFES. «d 

NXS SYSJVENTJIBQUEST ^VESOTSEMEyTS. If the hob is already * 
member of the territory, U sends its ron*^ to the se nder with 
NXS SYS EVENT_NEW JWXJTES. The leceavmg nub always requests rontes from 
the sender Vim r«S„SY3^EVTKTJlEQXJESTJ^0inES, If the enr mrrrinn cannot 
30 be created, for example the territory name a wrong, the receiver sends a 

UXSJS YS_EVENT_CO*WBCT_FAi LED 

/string/ Sending hub name 

35 /string/ Sending hub territory 

/string/ Beaaoa for connection failure 

Sent when connection estabashmeni failed. CVan up data stroctures. 



NXS_SYS_EVErfTJ*SC^^ 

/string/ Sending bub name (or neighbor name) 

/string/ Sending bub territory 

This system event can be sect to tetf or to another hub. Sent to self as a result of call to 
Hrrm A /4m™-gnhA Aninr dSsrrrn rct rTnh. m this case, the first argument ts the name 
of the neighbor bob. The hub sends a similar event to the neighbor ( cortrt mmg the name 
of the sending tab) and does a mnectioo shutdown. This may cane Che 
sy^^vents to be sent: rOCS.SYS^VWrjAIL^SUBSaaPTlOl^ 
NXS SYSJVTNTJPrXETrLBOUTES. 

NXS~SYS EVENT J>ELETE_ADVbK 1 lJihMENTS. One the craw en n n clean-ap 
. a NXS.SYS JVENT JEND_OF.STREAM b delivered. 
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Repeated A times, 
string/ Advertisement rvame 

string/ Event type name 

ong Priority 

Storage mods; "p- or «f for persistent or tran- 
sient 

along Time to live (seconds) 

•string/ Originating hub name 

/string/ Originating hub territory 

Creuc RjynoteAds-for the tisttd sdverasemenn. The originating bub is where the 
advertisement* was created. Tbc system event is farwtnicd to til connected neighbors 
excepted the sayicr'tr^ ocighbOT wbo have already seen tbc event. 



NXS.SYS.EYENT^CONNECnON.READY 

/string/ Sending hub name 

/string/ Sending hub territory 



Tbc f^'Hig bub is ready to use tbc connrrrinn If tbc receiver is also ready. U replies 
with i r«S.SYS„EVENT„COfWECnON.RE^ If the CTcoectioQ is already 
gtl ^KhM the system event is ignored. 

NXS^SYS^EVENT^FO RWAR0_ ADVEHTISEM ENT 
string Advertisement n*am 

Send the advertiseineni to ail co rtwv jrd neighbors. Only sent to self when 

advertisements are creased. 

NXS^SYS.EVENT.CHAMGE.AOVERTSOyiEKT 

/string/ Advertisement name 

/string/ Originating hub name 

/string/ Originating hub territory 

long; Priority 

string Stor*g« aoda; -p- or *t* for persistent or tran- 
sient 

along Time to live 

Update the f«f*™g RensoteAd with (be given v lines. The system event is forwarded 
to til neighbors except the sender and hubs that have already seen tbc evenL 

KXS_SYS_EVENT_DEL£TC_ADVERTtSEMr^fTS 

long Kumber of Advertisements A 

Repeated A Ciaes: 
/string/ Xdvertiaenent name 

/string/ Originating hub nam* 

/string/ Originating hub territory 
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Tha Sy**** 11 Events 



/string/ Advertisement name 

/string/ originating hub name 

/sLnng/ Originating hub territory 

Delete the rouies (AdSoura) for the given .dvcmsen^QC Any 
Hindoos which were fed by that route are failed, "y result in 
KXS SYS EVEKT.FAIL.SUBSCRIPTIONS scm to t^ont who have 
sur^ptioas regis*red for the advcrnsrmrnr ftxwardmg of each delved route is 
cor^aered separately andonxytftheUstrouietothe advertisement was deleted. The 
system event is Dot forwarded to the sender or the originating hub. 

NXS.SYS.EVENT^CHANQE.COfWECrnON 

/string/ Sending hub name 

/string/ Sending hub territory 

long Delta to sending bub' a connection coat 

Update their cost for the cooDecooa. 

KX5.SYS_EYENT_riEW_SUBSCRIFnOflS 

long Wi*nber of subscription* S 

Repmtfd S tuna: 

/string/ Advertisement name 

/string/ Advertisement bub name 

/string/ Advertisement bub territory 

/string/ Filter expression 

ulong Owner id in sender 

ulong Subscription id in sender 

Register subscriptions from the sender against the given advertisements. Create a 
Subscxipcian on the sending n 

ells the current AdSoarce which create* a Sink for the Neighbor (if one does not yet 
exist). The Sink adds a SobacripooaRef for the Subscription. 

If ifae advertisement b from another hob. forward a system event for the new 
subscription to the neighbor (applying the < inm i f roam. 

The owner and subscription ids are used to locaae the subscription when it is canceled 
and to identify U when it fails. 

If there is a failure during subscription registration, an 
NXS_SYS_EVENT J=AJL_SUBSOUrTK)KS b returned to the sender. 

NXS.SYS.EYQIT.CANCeL.SU BSCHtFTK>NS 

long Number of subscript ions 5 

Reputed S time*; 
uiong Owner id In sender 

ulong Subscription id in sender 
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the network, the method comprising the steps, performed by the data processing system, of: 

providing a link so that the data base can communicate with a data base connector computer program by way 
of a transaction monitor computer program; 

setting up the data base connector as a publisher hub in the network; 
receiving input, by the data base, from a user that alters data in the data base; 
informing the transaction monitor that the data has been altered; 
receiving input from the user indicating that the altered data should be committed; 
informing the transaction monitor that the altered data is committed; and 

seeing by the data base connector, in accordance with a message from the transacts monrtor that the data 
is committed, a published event to the network in accordance with the altered data. 

2. The method of claim 1 . further including the steps of: 

receiving input from the user indicating that the altered data should be rolled back; 

informing the transaction monitor that the altered data is rolled back; and lh ^ rn \i 
ref rS. by the data base connector, from sending the altered data to the network in accordance w.th the roll- 

back. 

A method of connecting a data base to a publisher/subscriber network, so that the data base can subscribe to 
events to the network, the method comprising the steps, performed by the data processmg system, of. 

providing a link so that a data base connector computer program can communicate with the data base; 
setting up the data base connector as a subscriber hub in the network, 
receivina by the data base connector, an event from the network; 

sending by the data base connector, data in accordance with the received event to the data base; and 
committing, by the data base connector, the data in the data base. 

4. The method of claim 1 . further comprising the step of: 

sending the event, by the data base connector, to one of its neighbor hubs, where a data structure in the data 
base connector indicates that the neighbor hub is on the least-cost path to a subscriber for the event. 

5. The method of claim 1 . further comprising the steps of: 

receivina an event by the data base connector; 

SermiLg. by the La base connector, in accordance with a data structure of the data base connector, that 

the data base has subscribed to the event; and 

sending, by the data base connector, the event to the data base. 

6. The method of claim 1 . further comprising the step of: 

receiving an event, by the data base connector; , „ rtrtrta ^r ihat 

determining by the data base connector, in accordance with a data structure of the data base connecto , that 
ESS hub ^connected either direct.y or indirectly on the least-cost path to a subscriber for the *,en and 
sending, by the data base connector, the event to its neighbor hub. so that the event can be forwarded to the 
subscriber. 

7. The method of claim 1 . wherein the sending step includes the step of: 

sending an event, by the data base connector, to one of its neighbor hubs when a data structure in the data 
base connector indicates that the data base subscribes to events having the type of the event. 

8. The method of claim 1 . wherein the sending step includes the step of : 

sendina an event by the data base connector, to one of its neighbor hubs when a content f ilter in a data struc- 
fur^oHhe ^dToasVconnector indicates that the data base subscribes to events having values found .n the 

event. 
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